中国民生银行：智能运维引领数据中心数字化转型

大家下午好！

今天我演讲的题目是《智能运维引领数据中心数字化转型》，跟大家分享民生银行在智能运维领域的探索和实践。

01 数字化转型，运维新挑战

金融行业是对信息技术应用最为广泛和彻底的行业。首先，我从民生银行的角度，向大家简要介绍一下银行业科技的演进趋势。

2000年初，我们进行了银行系统大集中，建设了管理银行账户的单体核心应用系统，当时用户需要去网点办理业务，而随着互联网发展和个人主机的普及，银行开通了网上渠道。到了2012年，民生银行完成了基于SOA架构的新一代核心系统投产，以面向服务的架构重构了整个业务体系，对业务的支持能力进一步加强，从原来只是实现业务需求变成紧跟业务战略发展，支撑银行业务的持续发展。

近几年，随着金融科技和互联网金融的发展，银行业务和IT架构有了非常大的变化。现在民生银行基于分布式和微服务技术，自主研发并投产了分布式核心系统，把银行账户体系和业务系统迁移到分布式架构上来。分布式核心系统采用了多中心的部署架构，能够支撑海量的并发访问。基于 “薄前台、强中台、稳后台”的思路，我们对业务与应用架构也进行了升级，持续进行信息系统的构架转型，以敏捷的方式满足客户需求，支撑业务发展。金融科技赋能业务创新，进一步提升了客户服务水平。

刚刚过去的2020年，大家经历了非常不一样的一年。年初疫情突发，武汉封城，由民生银行首创的“7*12小时”远程银行服务，应用音视频传输与解码、数据交互及加密传输、物联网等技术，在业内率先实现了基于手机银行的多场景个人和对公业务服务，远程柜员在线办理、全流程无纸化服务及数据化交互体验，真正实现了“突破时空限制”，“实时在线”、“全程无接触”服务，让用户在疫情中感受到民生银行的暖心服务。

同时，民生银行聚焦提升客户体验，打造有温度的银行。一方面积极利用人工智能、云计算、边缘计算、自然语言处理等前沿技术，业内首发5G手机银行，围绕交互体验与智能服务打造六大亮点，颠覆了传统手机银行服务模式。另一方面打造小微金融3.0模式，以数据、工具、系统平台为基础，围绕小微客户的生意圈和生活圈，定制综合金融解决方案，全面满足客户需求，着力提升差异化、精细化服务水平。

总体来说，随着产品推陈出新和流程优化改进，银行业务越来越注重客户体验，能够快速响应客户需求，提供更优质的银行服务。而这些服务和系统都运行在数据中心，数据中心的各种设备、技术栈和系统关系越来越复杂。从物理服务器到虚拟化云平台，从商业产品到开源技术，从集中式架构到分布式架构，这些都给运维带来了更大的挑战。如何应对新挑战是我们当下面临的严峻课题。

那么，我们现在面临哪些挑战呢？首先，银行与互联网企业不一样，互联网企业采用的技术栈比较新，而我们的银行系统从二十年前的系统大集中发展到现在，处于新老架构并行和双栈运行的状态，运行环境更为复杂；

其次，业务创新速度快，要求频繁发版。基本上，我们每周都会做版本发布，但因为系统的云化和微服务化，每次版本发布都会对系统的稳定性运行带来很大的影响，如何做好影响分析和控制变更风险是我们面临的重要课题；

再次，数据中心技术专业条线多，需要运维人员具有“十八般武艺”，维护系统的稳定运行需要依赖运维专家的独特经验，而运维专家经验难以复用；

然后，因为技术新老不一，应用架构标准化程度不一样，我们有运行时间超过10年的应用，也有新开发的应用，这进一步增加了运维的复杂性；

最后，随着大数据技术的发展和监管控运维工具的完善，我们有非常丰富的运维数据，但存在“数据孤岛”问题，各专业条线的数据不易做共享。

02  数据驱动运维

为了应对挑战，民生银行采用“数据驱动运维”战略来解决目前面临的运维难题。“数据驱动运维”战略围绕以下几个方面展开：

一、感知能力

我们在数据中心的建设过程当中，应用数字孪生技术，把运维对象数字化，构建可视化的界面。运维人员通过界面可以直观看到系统的运行状况。同时，我们的监控平台覆盖了运维全领域，拥有维度丰富的数据，再通过智能运维算法智能发现故障，对数据中心整个运行组件做到全感知。

二、决策能力

以往单纯依赖运维专家的过程主要是人工决策，当然人工决策对数据中心来说依然很重要。现在我们采用了“可视化+专家大脑”去做人工决策，同时通过“大数据+机器学习” 来智能决策。

三、执行能力

有感知有决策，当服务质量有所下降或出现故障的时候，要怎么去恢复服务、降低故障恢复时间？这就需要在执行能力方面下功夫。我们建设了标准化流程、标准化动作、标准化场景，之后再通过自动化运维系统固化起来，在出现对应的故障的时候，可以采用一键恢复的方式，来提高问题处理的效率。

四、数据底座

要建设上面提到的三种能力，数据底座是基础。前面提到，我们运维工具很多，数据很丰富，但因为“数据孤岛”加上数据维度庞杂，构建统一的运维数据中台作为底座就非常重要，在数据底座建设上我们下了很多功夫。

五、组织转型

数据中心都是各个领域的技术专家，网络专家精专于网络知识，系统专家负责系统。而采用智能运维的方式时，运维感知和决策建立在数据的基础上，这时候就需要组织做相应的转型。我们采用了Google SRE的理念，来提高运维开发能力，提升运维效率。

我们认为，数据驱动运维的落地不单单依赖一个简单的平台，而是数据中心所有工具平台的有效整合和集成。上图右侧“落地产品”就是目前我们采用的一些平台和工具。

这里，再跟大家分享一下数据底座的建设。我们大概从2018年开始做数据底座建设，遇到很大的问题是运维数据治理。我们之前的运维数据标准化程度不够高，想用算法消费数据来提供感知和决策能力时，就必须先做数据治理。因此，我们对所有的数据做了摸底，建立运维数据的标准，并且通过自动化程序和配置采集程序来采集标准数据，经过加工汇总到28个数据模型，最后汇聚到数据运维中台上，对外提供数据消费的接口。接下来做智能运维，数据直接来自于数据中台的数据服务。这个过程中，数据治理是难度比较大的一件事情，我们花了很大精力，目前也在根据一些运维场景不断地优化和完善。

运维数据中台提供数据资产加工和数据服务的能力，高效满足前台数据分析和应用的需求，总结为以下四点：

• 其一、基于大数据平台，通过Spark/Flink集群的实时计算，达到秒级响应、实时计算的能力，提供大吞吐量的数据处理能力；

• 其二、全量数据，目前每天有20TB的数据量，每分钟有百万级的监控指标，每天有数亿笔的交易明细，这些全部集中到数据底座进行加工；

• 其三、数据治理，数据经过加工清理，然后分门别类存放；

• 其四、在提供易用的应用开发接口之后，组织运维小组按照场景进行攻关，利用运维数据中台的数据去做开发，取得了比较明显的效果。

接下来谈一下组织转型，下图是我们实际的行政组织，应用运维中心是按照银行业务划分的组，其他是按照技术条线进行分组，我们在做数据驱动运维转型的时候，形成了跨各个中心的运维数据中台虚拟组、智能运维虚拟组和可视化虚拟组，分专题进行专项攻关。对于运维工具的建设，我们站在整个数据中心层面来统筹安排，协调资源，统一建设。现在看起来，这种方式取得了比较好的效果。

回到今天智能运维的主题，其实现在业界对智能运维的范围界定并不是很清晰，狭义的智能运维是指利用数据+算法来获得数据系统运行的感知和决策能力，我们目前是按照狭义目标来进行探索和实践，智能地进行自动化操作暂时还没有覆盖。

这几年我们在智能运维方面主要做了以下工作：在故障发现层面，做KPI指标异常检测、应用日志异常检测；在故障分析层面，做调用链分析和多维分析；在系统画像方面，分析系统健康状况、系统应用架构、系统提供的服务类型；在故障预测方面，根据性能指标趋势来预测未来可能产生故障的时点，便于做主动性防御；对于性能瓶颈，我们做了周期性、主动性容量评估的尝试；在知识图谱方面，我们尝试构建数据中心各个运行组件之间的关系，告警以及运维知识库内容的关联，通过知识图谱的方式把实体和关系关联起来，然后按图索骥，在告警出现时找到对应的解决方案。

03 民生智能运维实践分享

民生银行异常检测和故障定位主要聚焦两个方面：横向定位故障系统，定位到哪个系统出了问题；纵向定位故障原因，找到系统中哪个组件出了问题，原因是什么？

下图左侧是我们需要用到的数据，在横向故障定位的时候，需要用系统调用数据以及系统间服务调用数据来分析；在下一层应用架构逻辑部署关系上，利用好应用模块关系、应用部署关系以及服务内部逻辑；在底层用传统软件模块上，根据各自模块的特点，各个突破，找到各自的故障定位逻辑；在基础设施方面，我们对服务器、交换机和存储也有详尽的数据。

从问题解决路径来看，首先是要发现故障，在可用性故障发现层面，根据系统的可用性指标和特殊的单指标，通过机器学习发现这个指标的规律，如果出现异常能够做到及时告警；在日志异常检测层面，通过构建日志模板发现系统异常。

在发现异常后会进行故障影响分析，通过交易明细数据界定影响的范围。影响的是分行机构，还是全行层面，还是某个第三方？可以清晰地界定出来。

分析出影响范围后，进一步定位问题根因，通过调用链分析定位到具体哪个应用模块出了问题，接下来去找具体原因跟解决方案。是数据库的问题，还是应用的问题？还是底层虚拟机的问题，或者网络问题？需要在各个组件层面进行深入定位，然后通过可视化的方式提示根因，并且推荐出相应的解决方案。

以上是我们日常做故障处理的流程，以及用到的一些智能运维技术。

故障发现

其实，做故障发现不是一件容易的事情。我们要做故障发现算法一定要适用于各个系统，但银行各个系统的运行特点不一样，比如性能指标每天的曲线、每周的曲线、每月的曲线都不一样，所以做智能运维算法的时候要做很多考量，比如考虑系统批处理时间的影响，识别一些指标的陡升陡降，因为一些业务的关停或新开，可能就会出现陡升陡降的情况。再比如春节、国庆等节假日，指标与平时不一样，也需要算法有效识别出来，保证故障异常发现的准确性。这规避了传统监控方法要设置不同的阈值，而且阈值要根据业务变化进行人工调整。现在我们直接用智能算法就能检测业务KPI的异常。

调用链分析

如今大家使用手机银行比较多，它对银行整体业务的替代率在90%以上，但是每个业务并不是手机银行独立提供，而是依赖于后台的很多系统，比如业务集成系统、产品系统、核心账户系统等，这是一个很长的调用链，而且调用链也不是一个简单的单流程，可能涉及到多次业务查询和账务操作，才能完成一笔交易。在调用链出来之后，大家就会发现它其实很复杂。

当系统出现异常的时候，我们要找出真正导致异常的调用链和根因，首先要把调用链构建出来，之后采用算法做异常调用剪枝，保留异常调用链路，再进行组合排序来评判它的异常程度，最终确定到底哪个异常调用的链路才是故障的根因。

多维特征分析

大家用Excel的时候，经常会做一些数据分析或者数据筛选，可以从不同角度勾选不同的维度，来观察相应的数据。我们做的多维特征分析，是通过算法把数据进行组合、分组和计算，再跟正常情况进行对比，快速找出交叉维度组合，并支持下钻分析。

从下图右下方可以看出，通过多维特征分析，可以直观看到异常交易类型是什么、调用交易的源系统是哪一个、调用返回码是什么。我们通过智能运维算法直接把多维数据分析结果显现出来，省去逐步查看日志、查看系统监控指标、分析数据和原因的过程，节省了大量的时间和人力。

基础软件故障定位

刚才讲到调用链的分析，我们系统间的故障定位基本上基于交易指标，把系统运行的一些黄金指标拿来去做运算。系统运行出现异常一定是组成系统的某个组件出了问题，也许是一个外部服务，也许是一个数据库，也许是一个消息队列。由于每一类应用软件的工作原理和指标都不一样，就需要非常丰富的专家知识去解决这个问题。

我们在做基础软件故障定位时，其实是借助运维专家的专家知识，梳理成一个指标的集合，对指标进行整体的管理管控，同时构建指标之间的影响关系图，然后可以用一些算法去定位系统中到底哪个指标出了异常。这是我们现在在数据库层面做的故障定位，可以做到一键定位问题，分析出数据库里面运行的Top SQL，及时发现SQL执行效率降低的问题。

这里讲一个案例，之前有一个系统响应时间变慢，我们快速故障定位发现是本系统出了问题，通过智能算法的可视化路径看到应用服务器各项指标是正常的，数据库有一些异常的情况出现。我们进一步通过基础软件故障定位，找到是数据库有一个指标产生异常——磁盘写日志缓慢，导致数据库的响应效率降低，进而引起应用系统的响应速度变慢。

日志故障定位

应用系统运行时都会打印运行日志，而运维人员会花很多时间去查看系统日志，发现应用程序运行到什么步骤出的问题，再根据代码排查根因。然而随着系统规模的增大，一个系统可能有几百台服务器，每台服务器上的应用服务器都会产生大量的日志，这时候怎么快速定位出问题的节点、出问题的日志，根因又是什么？这给我们带来了很大的挑战，也是我们启动日志故障定位的原因。

首先通过ELK平台把日志收集到一起，然后通过智能算法对日志文件做训练，创建出日志模板，并建立基线，最后根据日志模板对日志进行实时检测分析。因为系统在运行的时候，它的行为是有规律可循的，像系统正常运行时错误日志就很少，所以我们通过把正常运行的日志模板提取出来，再根据日志模板实时对日志进行异常检测的时候，如果说日志出现了不符合基线的异常日志点，可能就是系统出现问题了，可能是某类日志突然打多了，或者是日志里有些取值或者变量分布发生了变化。比如Web服务器访问返回码正常是200，突然一下子出现了很多4XX的返回码，就可以通过web服务器日志发现系统异常。

这是我们做日志故障定位的思路，当出现问题的时候，通过日志故障定位功能分析日志是否异常，是哪个组件出现了异常，再根据异常做进一步处置。

经过几年的时间，民生银行智能运维实践积累了一些经验。首先是数据先行，把数据中心各个运维工具的数据做治理，统一到相应的运维数据中台，这样我们就有了数据底座，有了数据处理和服务能力。

其次是算法创新。人工智能发展到现在，像语音识别、图像识别等技术已经很成熟，但这些都属于特定领域的算法。从运维来讲，我们碰到的场景是异常复杂的，标准化程度也没有那么高，所以做异常检测和故障定位时需要在算法上做创新，可以对一些经典的算法进行组合使用。

最后是场景驱动。刚开始做智能运维难度很大，因为这是一个全新的课题，所以我们当时决定通过场景驱动的方式，找到日常运维工作中特别难、特别慢、特别繁琐又亟需提升效率的场景，集中精力去突破，通过“算法+数据”的方式来简化运维工作。

在本届国际AIOps挑战赛中，我们提供了真实的业务系统，输出相应的基础软件监控指标、系统运行的交易服务指标、系统调用链数据和日志数据，供选手们来做故障检测和根因定位。

预祝各位选手在2021国际AIOps挑战赛中取得好成绩，祝AIOps挑战赛圆满成功，谢谢大家！

 精彩Q&A 

此次主题演讲聚焦中国民生银行的智能运维探索，分享业务实践下的AIOps落地成果和经验，引发了线上观众的热情提问与讨论。根据现场答疑内容整理如下：

是否可以分享一下知识图谱在民生银行的使用场景以及解决的问题？

A:

民生银行数据中心在知识图谱方面的主要思路是：一、基于现有的配置管理数据，涉及应用系统之间的调用关系，以及应用系统内的调用关系，包括各个应用组件、服务器、交换机和存储设备等。二、把告警和告警处理方法形成知识库，尝试用知识图谱进行关联。这样一来，我们搜索告警的时候，就能快速找到告警发生在哪个组件、会影响哪些组件，推荐针对该告警的解决方案。

民生银行引入AIOps后落地应用有多少？在效率提升方面有没有量化数据？

A:

目前，民生银行主要是对实时交易系统接入了智能运维，落地系统有80余套。在智能运维的效率提升方面，对于一些可能影响客户的生产事件，我们对故障发现和根因定位的准确率有要求。2020年，从已经接入AIOps的系统来看，故障发现率在86%，根因定位准确率在66%。同时，关于故障修复时间，民生银行数据中心制定了“双十”要求，即10分钟定位故障、10分钟恢复服务。现实情况还未完全达到这个标准，我们今后会进一步提升智能运维水平。

民生银行在智能运维方面投入的人员配比是什么样的？

A:

我们不是一个部门或者一个团队去做智能运维，而是涵盖数据中心各个技术团队组成虚拟小组，从运维数据处理到数据标准化、再到智能运维算法，核心投入成员二三十人。这些核心成员在完成本职工作的同时，参与到智能运维探索和研究。他们有丰富的运维经验和领域知识，对运维有很深的理解，有助于智能运维实践取得更好的效果。

本文转载自公众号：民生运维人，点击查看原文

↓↓ 点击"阅读原文" 【加入云技术社区】

相关阅读：

更多文章请关注

文章好看点这里[在看]👇